Databases are used for accepting, storing, and providing, on demand, data for multiple users. A database serves as a central repository of data which can be accessed by any number of different computers and users at any time. Databases find use in many different fields, such as for storing medical information, financial transactions, web sites, etc. Indeed, databases are becoming crucial to the operation of many companies. For example, a production database is often used by a company to track orders placed by customers, control inventory, monitor the workflow during assembly, generate invoices, etc.
Unfortunately, databases are susceptible to becoming disabled due to hardware breakdowns, software glitches, network hangups, accidents, disasters, human error, etc. In many instances, it would be catastrophic if data could not be accessed, or worse, if data were to be permanently lost due to a database failure. Because there can never be a guarantee that a database is always up and running, companies have implemented backup databases. And depending on the degree of importance of the data or function of a particular database, several different copies of the same data are often archived in multiple databases at different geographical locations on different storage facilities. In case of a failure in the primary operational database, the company can rely on the backup database. The company can switch from the primary operational database to the backup database in a matter of minutes.
Since data in the primary database is constantly being added, deleted, or otherwise modified, the backup database must likewise be updated so that it contains a mirror copy of the data residing on the primary database. Rather than copying over the entire database each and every time the operational database is updated, the backup database is periodically updated by copying over only the new changes since the previous update. For instance, the operational database can create an archive log which is used to store a pre-determined number of new transactions. When the archive log is full, that archive log is sent to the backup database. The backup database stores the archive log. In this manner, the backup database is kept current.
Although this archive process is simple and straightforward, it suffers from several drawbacks. One very important issue is that if a database administrator inadvertently removes a log on the receiving host, it will need to be manually recopied because prior art processes would only copy a log once and then move on. There is no mechanism for recopying. A related issue is that there is an inherent amount of danger in corrupting or deleting a log file as it is being manually recopied. In that event, the backup database on the receiving side is nullified and needs to be fully recopied. This is highly undesirable as it causes downtime for clients and a copious amount of human labor must be exerted just to return service to the application.
Another issue with the prior art archiving processes is that they could only sequentially transfer one log at a time. If there were a backlog or a delay (e.g., loss of network connectivity), logs would pile up on the sending host, thereby resulting in the data on the backup database becoming more and more stale. There is no real way to recoup from a backlog other than to manually copy many logs in batch mode and risking data loss or corruption through human error.
Therefore, there exists a need in the prior art for an improved archiving process. The present invention provides a unique, novel solution to these and other archival problems.